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SUMMARY  SAINT  Is  an  acronymn  for:  Systems  Analysis  of  Integrated  Networks  of  Tasks.  SAINT  is  a  network 
modeling  and  simulation  technique  for  design  and  analysis  of  complex  man-machine  systems.  SAINT  provides 
the  conceptual  framework  for  representing  systems  that  consist  of  discrete  task  elements,  continuous  state 
variables,  and  interactions  between  them.  It  facilitates  an  assessment  of  the  contribution  system  compo¬ 
nents  make  to  overall  system  performance.  A  preprocessor  routine  is  available  to  create  DIMENSION  state¬ 
ments  for  the  source  program  that  are  tailored  to  the  size  requirements  of  the  problem  being  treated.  Pro¬ 
visions  are  made  for  structuring  model  outputs  for  post-run  processing,  using  available  statistical  analy¬ 
sis  packages.  Extensive  error  checking  routines  are  al*'«  provided  in  SAINT. 


1  INTRODUCTION 

SAINT  is  a  computer  simulation  tool  for  modeling 
and  analyzing  man-machine  systems.  While  SAINT  was 
designed  for  modeling  manned  systems  in  which  human 
performance  is  a  major  concern,  it  is  potentially 
applicable  to  a  broad  class  of  problems — those  in 
which  discrete  and  continuous  elements  are  to  be 
portrayed  and  the  behavior  exhibits  time  varying 
properties.  SAINT  provides  a  mechanism  for  de¬ 
scribing  these  dynamics  so  analyses  can  be  perform¬ 
ed. 

SAINT  evolved  from  two  separate  technologies.  Task 
analysis  and  the  Monte  Carlo  simulation  of  operator 
performance  under  workload  stress  as  represented  by 
Siegel  and  Wolf  (1967),  were  the  origin  for  the  hu¬ 
man  factors  development.  Many  of  the  features 
eventually  incorporated  into  SAINT  were  identified 
as  requirements  based  upon  experience  in  applying 
this  technology.  The  second  origin  of  SAINT  was  in 
the  GASP  family  of  simulation  techniques  (Pritsker, 
1974).  The  earliest  version  of  SAINT  was  an  incor¬ 
poration  of  the  Siegel-Wolf  model  in  a  modified  P- 
GERT  package  (Pritsker,  et  al.,  1974).  The  subse¬ 
quent  evolution  of  SAINT  adapted  features  of  GASP 
IV  and  allowed  SAINT  to  become  a  flexible,  sophis¬ 
ticated,  combined  modeling  technique  where  networks 
of  discrete  events  could  be  modeled  along  with  the 
dynamics  of  continuous  processes. 

It  is  this  ability  to  combine  models  of  dynamics 
(e.g.,  aircraft  equations  of  motion)  with  models  of 
discrete  activity  sequences  (e.g.,  operator  actions) 
that  permit  the  systems  analyst  to  describe  both 
hardware  and  human  performance  in  the  context  of  a 
single  model.  This  affords  the  system  engineer  the 
opportunity  to  analyze  system  effectiveness  and 
quantify  the  relative  contributions  of  man  and 
machine . 

2  SAINT  CONCEPTS 

For  the  discrete  event  simulation,  a  graphical- 
network  approach  to  modeling  is  taken,  whereby  a 
user  of  SAINT  describes  the  system  to  be  analyzed 
via  a  network  model  and  auxiliary  descriptions 
(e.g.,  equipment  and  operator  performance  parame¬ 
ters).  (A  symbol  set  has  been  devised  for  diagram¬ 
ing  the  discrete  task  network.)  The  SAINT  computer 
simulation  program  accepts  a  description  of  the 


network  to  be  simulated  and  automatically  performs 
an  analysis  to  obtain  statistical  estimates  of  sys¬ 
tem  performance.  For  the  continuous  process  repre¬ 
sentation,  the  user  is  expected  to  provide  FORTRAN 
statements  of  the  relevant  state  equations  to  be 
solved.  Mechanisms  are  provided  for  creating  an 
interaction  between  the  discrete  and  continuous 
components  of  the  model. 

2.1  Discrete  Task-Oriented  Model  Component 

The  discrete  task-oriented  component  of  the  SAINT 
model  consists  of  nodes  and  branches,  each  node 
representing  a  task.  Tasks  are  described  by  a  set 
of  characteristics  (e.g.,  performance  time  duration, 
priority,  resource  requirements).  Branches  connect¬ 
ing  the  nodes  indicate  precedence  relations  and  are 
used  to  model  the  sequencing  and  looping  require¬ 
ments  among  the  tasks.  Complex  precedence  relations 
have  been  designed  into  SAINT  to  allow  predecessor- 
successor  relationships  which  are  deterministic, 
probabilistic,  and  conditional.  Resources,  either 
human  operators  or  hardware  equipment,  perform  the 
tasks  in  accordance  with  the  prescribed  precedence 
relations,  subject  to  resource  availability.  The 
precedence  relations  also  indicate  the  flow  of 
information  through  the  network.  Information  is 
organized  Into  packets  with  each  information  packet 
containing  attributes  that  characterize  the  infor¬ 
mation  being  processed.  The  information  packet  can 
characterize  items  flowing  through  the  network,  sig¬ 
nals  being  processed  by  the  network,  or  any  other 
concept  related  to  network  flow.  When  a  task  is 
completed,  the  information  packet  residing  at  the 
task  is  transmitted  along  each  precedence  branch 
selected.  Information  attribute  values  can  be  as¬ 
signed  or  modified  at  any  task  in  the  network  and 
can  influence  both  task  performance  times  and  task 
branching  relations. 

Resources  perform  tasks  either  individually  or  in 
groups.  Each  resource  included  in  a  SAINT  model  is 
described  by  a  set  of  attributes.  These  attributes 
are  also  organized  into  packets,  with  each  packet 
characterizing  a  particular  resource.  Examples  of 
operator  attributes  Include  such  things  as  level  of 
training,  age,  height,  etc.  Machine  reliability  is 
an  example  of  an  equipment  attribute.  Resource  at¬ 
tributes  are  used  in  conjunction  with  the  task  de¬ 
scriptions  in  order  to  mahe  a  general  network  model 
resource-specific.  The  initial  values  of  these 


user-def ined  resource  attributes  are  assigned  prior 
to  the  start  of  the  simulation.  The  values  may  be 
dynamically  changed  at  any  task  in  the  network  and 
can  be  used  as  parameters  in  determining  both  task 
performance  times  and  precedence  relations. 

In  many  instances  it  may  be  desirable  to  specify 
attributes  which  are  not  directly  applicable  to  an 
information-oriented  or  resource-oriented  charac¬ 
terization.  These  attributes  are  global  in  nature 
and  do  not  flow  through  or  move  about  the  network 
as  information  and  resource  packets  do.  Tempera¬ 
ture  and  time  remaining  in  a  mission  are  examples 
of  model  parameters  which  may  be  characterized  as 
system  attributes.  Just  as  with  information  and 
resource  attributes,  system  attributes  may  influ¬ 
ence  the  task  network  performance  and  flow. 

Each  task  in  a  SAINT  network  has  two  requirements 
which  must  be  satisfied  before  the  task  can  be  per¬ 
formed.  First,  a  specified  number  of  predecessor 
tasks  must  be  completed  before  the  task  is  released. 
Second,  once  the  task  has  been  released,  the  re¬ 
sources  required  to  perform  the  task  must  be  avail¬ 
able,  (that  is,  not  be  busy  performing  other 
tasks).  All  tasks  which  have  been  released  (all 
predecessor  requirements  have  been  satisfied)  but 
whose  required  resources  are  not  available  are  rank¬ 
ed  in  a  queue  according  to  their  priority.  Task 
priority  may  be  assigned  at  the  start  of  the  simu¬ 
lation  and  may  change  dynamically  as  a  function  of 
system  parameters  and  contingencies.  When  the  re¬ 
quired  resources  become  available  with  task  com¬ 
pletions,  the  tasks  in  the  waiting  queue  are  start¬ 
ed.  The  time  to  perform  a  task  may  be  specified  as 
a  random  variable  defined  by  a  probability  distri¬ 
bution.  SAINT  supplies  the  user  with  11  different 
distributions  (Normal,  f>amma.  Beta,  Weibull,  etc.; 
see  Hastings  and  Peacock,  1975). 

Frequently  the  task  performance  time  is  also  a 
function  of  the  type  of  task,  the  resource  or  re¬ 
sources  performing  the  task,  the  status  of  the  sys¬ 
tem,  or  the  condition  of  the  environment  at  the 
time  the  task  is  executed.  SAINT  provides  for  the 
specification  of  factors  which  influence  task  per¬ 
formance  via  user-written  moderator  functions.  It 
Is  presumed  the  modeler  can  describe  (e.g.,  by  least 
squares  techniques)  the  functional  relationships 
between  a  set  of  conditions  and  a  performance  pa¬ 
rameter  or  attribute  of  interest.  For  example,  one 
might  hypothesize  that  fatigue  affects  operator 
performance  sach  that  the  average  task  time  in¬ 
creases  as  a  function  of  mission  duration.  Re¬ 
search  data  must  be  obtained  tc  postulate  the  func¬ 
tional  form  of  this  relationship  and  fit  a  curve  to 
these  results.  This  empirically  derived  relation¬ 
ship  cat:  then  be  implemented  in  SAINT  as  a  moderator 
function  to  detwrmint*  the  nosslble  Imoact  fatigue 
could  have  on  operator  performance.  In  addition  to 
moderator  functions,  user-written  functions  can  be 
developed  for  specifying  attribute  assignments. 

Both  types  of  functions  are  written  in  FORTRAN  or  a 
FORTRAN-compatible  language. 


Contingencies,  decision  making,  and  emergency  con¬ 
ditions  can  be  represented  via  SAINT's  flexible 
attribute  assignment  and  branching  logic.  SAINT 
provides  two  additional  mechanisms  for  modeling 
system  performance. 

The  first  of  these  is  termed  task  modification. 

This  feature  enables  the  user  to  modify  task  param¬ 
eters  as  a  function  of  ongoing  system  events.  For 
example,  consider  a  task  which  may  require  repeti¬ 
tion  due  to  a  possibility  of  failure  on  the  first 
attempt.  The  second  time  the  task  is  performed  the 
performance  time  may  be  significantly  smaller  than 


the  initial  execution.  SAINT  provides  for  the  mod¬ 
ification  of  the  task  time  distribution  after  the 
initial  attempt.  Other  task  parameters  can  be 
modified  in  a  similar  fashion. 

The  second  SAINT  modeling  construct  of  interest  is 
"clearing."  Both  tasks  and  resources  can  be  clear¬ 
ed.  "Task"  clearing  halts  a  specified  task  in 
progress,  contingent  on  the  completion  of  another 
task.  "Resource"  clearing  halts  whatever  task  the 
specified  resource  is  performing.  Both  types  of 
clearing  may  specify  an  additional  task  to  be  sig¬ 
naled.  As  an  example,  consider  the  simulation  of 
an  emergency  condition  in  which  all  operators  must 
stop  their  ongoing  activities  to  assist  in  the  emer¬ 
gency  operations.  This  situation  is  best  modeled  in 
SAINT  with  resource  clearing.  The  onset  of  the  un¬ 
expected  event  would  "free-up"  (clear)  the  opera¬ 
tors.  Concurrently,  emergency  handling  tasks  would 
be  signaled  for  initiation  (and  release  if  all  other 
precedents  were  satisfied).  Task  and  resource 
clearing  provide  dynamic  realism  in  man-machine 
simulation  modeling. 

For  those  wishing  to  diagram  the  network,  the  symbol 
used  to  model  a  task  in  SAINT  is  illustrated  in 
Figure  1.  The  input  side  of  the  node  reflects  the 
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PR1  NUMBER  OF  PREDECESSOR  COMPLETIONS 
REQUIRED  FOR  FIRST  RELEASE  OF  THE 
TASK 

PR2  NUMBER  OF  PREDECESSOR  COMPLETIONS 
REQUIRED  FOR  SUBSEQUENT  RELEASE  OF 
THE  TASK 

TSK  TASK  NUMBER 

Figure  1  Task  Symbol 

precedence  requirements  for  releasing  a  task.  The 
number  of  requirements  for  releasing  a  task  the 
first  time  is  on  the  top  (PR1),  and  the  number  of 
requirements  for  releasing  a  task  on  subsequent 
times  is  on  the  bottom  (PR2). 

The  center  portion  of  the  task  symbol  contains  all 
task  description  information,  such  as  performance 
time  characteristics,  statistics  to  be  collected, 
and  attributes  to  be  assigned.  It  is  subdivided 
into  rows,  with  each  row  containing  a  specific  type 
of  descriptive  information  about  the  task.  Further, 
each  row  is  divided  into  two  parts.  The  left-hand 
part  contains  the  task  description  code.  It  is  used 
to  identify  the  type  of  information  that  appears  in 
the  right-hand  part  of  the  row,  and  can  be  any  of 
the  17  available  codes  shown  in  Table  I. 

The  LABL  permits  an  eight  character  identifier  to  be 
associated  with  this  node  to  depict  the  nature  of 
the  task/activity  represented.  The  TIME  character¬ 
istics,  when  specified,  indicate  the  distribution 
type  and  parameter  values  for  the  characterization 
of  task  duration.  If  activity  times  are  known  to  be 
a  function  of  specifiable  factors  (e.g.,  task,  sys¬ 
tem,  or  information  attributes),  a  moderator  func¬ 
tion  (MODF)  may  be  employed  (as  a  FORTRAN  subroutine) 
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TABLE  I 

TASK  DESCRIPTION  CODES 


additional  rows  to  the  bottom  of  the  task  descrip¬ 
tion  portion  of  the  task  symbol. 


LABL  task  label 

TIME  performance  time  characteristics 

MODF  moderator  functions 

DMOD  distribution  modification 

RESR  resource  requirements 

PRTY  priority 

INCM  information  choice  mode 

DIFF  different  predecessor  option 

PREC  completion  precedence 

UTCH  user-defined  task  characteristics 

ATAS  attribute  assignments 

STAT  statistics 

MARK  mark  information 

TCLR  task  clearing 

RCLR  resource  clearing 

SWIT  switching 

REGL  regulation 

to  generate  the  activity  duration  instead  of  gen¬ 
erating  a  time  value  by  Monte  Carlo  methods.  If 
Monte  Carlo  methods  are  employed  (via  TIME  speci¬ 
fication),  a  modification  can  be  effected  during 
model  execution  by  using  the  DMOD  feature  to  iden¬ 
tify  an  alternate  distribution  and/or  parameter  set 
when  specified  event  conditions  prevail.  RESR  may 
be  used  to  specify  the  type  and  quantity  of  re¬ 
sources  and  whether  multiple  resources  imply  sub¬ 
stitution  ("or")  rather  than  conjoint  ("and")  re¬ 
requirements.  If  priority  (PRTY)  is  a  concern,  it 
can  be  specified  apriori  and  subsequently  manipu¬ 
lated  dynamically  during  model  execution.  Since 
information  packets  can  arrive  at  a  task  from  sev¬ 
eral  sources,  but  only  one  will  exit,  it  is  nec¬ 
essary  to  specify  which  Incoming  packet  will  be 
passed  along,  INCM.  The  default  condition  for 
processing  information  packets  is  to  simply  pass 
the  last  one  arriving  at  the  node.  If  different 
predecessor  completions  are  required  in  order  for 
the  task  to  be  released,  the  DIFT  option  must  be 
specified.  Otherwise  the  multiple  occurrence  of 
any  predecessor  may  cause  the  task  to  be  prema¬ 
turely  released.  When  two  or  more  tasks  have 
identical  completion  times.  It  is  necessary  to 
specify  which  will  take  precedence  (PREC)  over  the 
others.  User-defined  task  characteristics 
(UTCH)  permit  the  user  to  specify  additional  at¬ 
tributes  of  a  task  (e.g.,  difficulty,  complexity, 
etc.),  and  these  attributes  can  be  modified  upon 
task  execution.  Information,  resource,  and  system 
attributes  can  be  assigned  or  updated  (ATAS)  upon 
task  release,  start,  or  completion  as  required. 

The  statistics  to  be  collected  (STAT)  are  described 
in  subsequent  discussion.  A  particular  task  can  be 
used  to  mark  the  start  point  (MARK)  for  timing  how 
long  it  takes  to  traverse  a  path  to  some  other  task 
of  interest.  The  MARK  feature  allows  elapsed  time 
computations  within  the  network  (e.g.,  time  between 
events).  Task  and  resource  clearing  operations  are 
established  by  specifying  the  appropriate  param¬ 
eters  associated  with  the  TCLR  and  RCLR  mnemomics. 
If  a  discrete  task  actually  affects  some  binary 
state  or  there  is  a  need  to  set  a  flag  for  some 
subsequent  processing  option,  SWIT  allows  a  switch 
to  be  set  (or  reset)  that  can  subsequently  be 
examined.  The  REGL  mnemonic  is  used  as  a  device 
for  regulating  values  employed  in  the  continuous 
process  model,  where  a  task  is  permitted  to  alter 
a  state  variable,  for  example. 

By  selectively  using  these  description  codes,  only 
the  information  necessary  to  describe  a  task  need 
be  shown  on  the  task  symbol.  In  this  manner,  any 
or  all  of  the  task  description  codes  can  be  speci¬ 
fied  for  a  particular  task.  If  more  than  the  four 
rows  provided  are  required  for  a  complete  descrip¬ 
tion,  the  user  simply  adds  the  necessary  number  of 


The  output  side  of  the  node  contains  the  task  num¬ 
ber  (TSK).  In  addition,  the  shape  of  the  output 
side  indicates  the  branching  operation  to  be  per¬ 
formed  upon  task  completion.  It  specifies  the  pro¬ 
cess  to  be  employed  in  selecting  the  successor 
tasks  whose  precedence  requirements  should  be  re¬ 
duced  by  one.  The  four  branching  types  Included  In 
SAINT  are  deterministic,  probabilistic,  conditional 
take-first,  and  conditional  take-all.  Their  shapes 
are  depicted  In  Figure  2. 
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Figure  2  Task  Branching  Symbolism 

When  deterministic  branching  is  specified,  the  num¬ 
ber  of  requirements  for  all  successor  tasks  is  re¬ 
duced  by  one.  For  probabilistic  branching,  each 
branch  emanating  from  the  task  has  an  associated 
probability  of  selection.  These  probabilities  may 
be  specified  directly  or  obtained  from  information, 
operator,  or  system  attributes.  Only  a  single  suc¬ 
cessor  task  is  selected.  For  conditional  take-first 
branching,  each  branch  has  an  associated  condition, 
and  the  branches  are  ordered.  Each  condition  is 
tested  in  the  prescribed  order,  and  the  first  branch 
whose  condition  is  satisfied  is  selected.  Condi¬ 
tional  take-all  branching  operates  In  the  same 
manner,  but  selects  all  branches  whose  conditions 
are  satisfied.  Conditions  may  be  based  on  task  com¬ 
pletions,  simulated  time,  or  attribute  values. 

The  above  discussion  only  Included  the  basic  task 
node  symbology.  Additional  symbolism  is  available 
for  task  modification,  task  signaling  as  a  result  of 
task  or  resource  clearing,  task  signaling  resulting 
from  a  threshold  crossing,  and  state  variable  moni¬ 
tors  (Wortman  et  al.  1977(a)  and  (b) ) . 

2.2  Continuous  State  Variable  Model  Component 

The  second  component  of  a  SAINT  model  is  the  state 
variable  description.  The  SAINT  user  defines  these 
state  variables  by  writing  the  algebraic,  difference, 
or  differential  equations  that  govern  their  time- 
dependent  behavior.  The  use  of  state  variables  in 
SAINT  is  optional. 


The  SAINT  user  writes  the  state  variable  equations 
in  a  FORTRAN  subroutine  (subroutine  STATE).  State 
variables  represented  by  algebraic  or  difference 
equations  are  defined  in  subroutine  STATE  as  SS(.) 
variables.  Those  represented  by  differential 
equations  are  written  in  terms  of  DD(.)  variables. 
SAINT  employs  a  Runge-Kutta-England  (RKE)  numerical 
algorithm  to  integrate  the  equations  of  subroutine 
STATE  written  in  terms  of  the  D0(.)  variables.  The 
RKE  algorithm  obtains  a  solution  to  a  set  of  simul¬ 
taneous  first  order  ordinary  differential  equations. 
Higher  order  differential  equations  can  be  modeled 
by  placing  the  equations  in  canonical  form.  Sub¬ 
routine  STATE  can  be  used  to  model  state  variables 
using  a  combination  of  DD(.)  and  SS(.)  variables. 

In  SAINT,  simulated  time  is  advanced  in  accordance 
with  the  type  of  system  being  modeled.  If  no  state 
variables  are  included,  simulated  time  is  advanced 
from  one  task  completion  to  the  next.  When  state 
variables  are  included  in  the  model,  time  is  also 
incremented  in  steps  between  scheduled  task  comple¬ 
tions  for  the  purpose  of  updating  the  values  of  the 
state  variables.  The  step  size  is  a  function  of 
user-specified  accuracy  requirements. 

2.3  Discrete  and  Continuous  Component  Interactions 

The  interactions  between  tasks  and  state  variables 
are  initiated  either  by  tasks  being  completed  or  by 
state  variables  crossing  specified  threshold  values . 
Upon  the  completion  of  a  task,  state  variables  may 
be  discretely  regulated  by  increasing  or  decreasing 
their  values.  In  addition,  task  completions  can 
change  the  values  of  logical  variables  which  can  be 
used  to  alter  state  variable  equation  forms  or  the 
network  structure.  In  this  manner  the  discrete 
task-oriented  component  of  the  model  affects  the 
continuous  state  variable  component. 

Threshold  crossings  by  state  variables  can  signal 
or  initiate  tasks.  Thus  the  values  of  state  vari¬ 
ables  can  influence  task  performance  characteris¬ 
tics  and  precedence  relations.  Threshold  crossings 
can  also  change  the  values  of  logical  variables 
which,  in  turn,  can  be  used  to  alter  equation 
forms  or  change  task  precedence. 

As  an  example  of  discrete  and  continuous  component 
interactions,  consider  a  system  in  which  a  pilot 
must  keep  the  aircraft  altitude  within  specified 
constraints.  The  pilot's  inputs  might  be  modeled 
as  discrete  tasks  and  the  aircraft  dynamics  as  con¬ 
tinuous  state  variables.  When  the  altitude  state 
variable  crosses  the  allowable  threshold  value,  the 
corresponding  discrete  pilot  correction  task  is 
signaled.  The  pilot  makes  the  appropriate  input 
and  regulates  the  state  variable (s)  which  determine 
altitude.  Thus,  through  this  component  inter¬ 
action,  the  aircraft  altitude  is  brought  back  with¬ 
in  acceptable  limits. 

3  STATISTICAL  OUTPUT 

Once  the  model  has  been  built,  the  modeler  can  im¬ 
pose  a  data  collection  structure  to  obtain  infor¬ 
mation  about  his  description  of  the  system  as  it  is 
exercised.  A  variety  of  data  can  be  obtained;  these 
fall  into  three  major  categories.  The  first  type  of 
output  is  a  statistical  description  of  the  execution 
of  specific  nodes  or  collections  of  nodes.  Table 
II  provides  some  insight  into  the  variety  of  pos¬ 
sible  measures  one  can  create  using  the  built-in 
features  of  SAINT.  Since  users  can  create  their 
own  functions  for  updating  attributes  and  for  mod¬ 
erating  network  parameters,  it  has  been  necessary 
to  allow  the  user  to  collect  his  own  statistics  on 
those  parts  of  the  model  which  cannot  be  predefined 


because  the  user  creates  them  himself.  SAINT 
supplies  statistical  subroutines  for  collecting 
data  on  user-supplied  parts  of  the  model.  Tabu¬ 
lar  summaries  of  the  computed  descriptive  statis¬ 
tics  can  then  bt  generated  to  portray  the  results 
of  a  single  iteration,  a  set  of  iterations,  or  a 
series  of  iterated  runs  showing  the  trends  induced 
by  some  systematic  variation  of  run  conditions. 


TABLE  II 

STATISTICS  CODES 


What 

When 

Release 

Start 

Completion 

Clearing 

First 

FIR  REL 

FIR  STA 

FIR  COM 

FIR  CLE 

All 

ALL  REL 

ALL  STA 

ALL  COM 

ALL  CLE 

Between 

BET  REL 

BET  STA 

BET  COM 

BET  CLE 

Number 

NUM  REL 

NUM  STA 

NUM  COM 

NUM  CLE 

The  second  type  of  output  is  a  graphic  portrayal  of 
the  probability  and  cumulative  density  functions 
for  a  distributed  variable.  They  provide  a  quick 
look  at  the  shape  of  the  data.  An  experienced 
user  can  store  the  actual  values  on  an  external 
device;  later,  the  data  can  be  fed  to  a  plotting 
package  for  reproducible  drawings. 

The  third  type  of  output  are  time  traces  of  the 
state  variables.  Up  to  10  variables  can  be  plotted 
on  the  same  graph  with  user  specified  scale  factors 
and  plotting  symbols.  Multiple  graphs  can  be  gen¬ 
erated.  Tabled  values  of  the  variables  can  also  be 
obtained.  Here  again,  an  experienced  programmer 
can  save  these  data  for  more  precise  plots.  The 
tabulated  plot  provided  by  SAINT  equips  the  user  to 
quickly  examine  the  results  of  his  simulation  run. 

4  THE  SAINT  PROGRAM 

Development  of  the  SAINT  simulation  package  has 
been  completed  and  is  fully  documented  (Wortman, 
et  al.,  1977a,  b  and  c  and  Duket,  et  al.,  1977). 
SAINT  was  developed  in  ANSI  standard  FORTRAN  and 
consequently,  is  machine-independent .  The  user, 
however,  must  supply  his  own  system-specific  random 
number  generator.  The  task  network  data  is  punched 
on  cards  in  free-form.  SAINT  Includes  an  extensive 
input  error-check  feature  to  assist  users  in  de¬ 
bugging  their  models.  For  production  runs,  users 
can  select  a  more  efficient  non-error-checking 
version  of  SAINT.  A  separate  FORTRAN  program  has 
been  devised  to  create  a  source  module  with  the 
COMMON  blocks  sized  to  the  problem  being  run. 

SAINT  also  includes  provisions  that  allow  formatting 
model  outputs  so  they  can  be  processed  by  available 
statistical  analysis  packages  (Wortman,  et  al., 
1977c). 

5  APPLICATIONS  OF  SAINT 

SAINT  has  been  used  to  analyze  a  wide  variety  of 
man-machine  systems.  It  is  gaining  a  wide  and 
enthusiastic  acceptance  by  systems  modelers  and 
analysts  of  many  disciplines.  The  following  is  a 
list  of  completed  or  ongoing  modeling  and  simu¬ 
lation  efforts  involving  the  use  of  SAINT:  SAINT 
has  been  used  by  the  Aerospace  Medical  Research 
Laboratory  (AMRL)  to  evaluate  alternatives  for  a 
Vehicle/Drone  Control  Facility  (RPV/DCF)  in  which 
operators  monitor  and  control  the  flight  of  RPV's 
through  the  use  of  visual  (CRT)  displays  (Wortman, 
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et  al . ,  1976).  SAINT  was  used,  also,  to  provide 
flight  control  performance  predictions  for  the 
Digital  Avionics  Information  System  (DAIS)  cockpit 
configuration  in  which  dedicated  instruments,  dis¬ 
plays,  and  subsystem  status  displays  have  been 
replaced  with  interactive  multipurpose  displays 
and  multifunction  keyboard  switching  (Kuperman 
and  Seifert,  1975).  SAINT  is  currently  being  used 
by  AMRL  to  provide  cost  trade  off  design  analyses 
of  three  proposed  configurations  for  the  UPD-X  All 
Weather  Wide  Area  Surveillance  ground  exploitation 
station.  AMRL  plans  to  utilize  SAINT  to  analyze 
design  proposals  in  a  B-52  strategic  navigation 
system  involving  complex  crew  activities  and  task 
management  (Chubb  and  Berisford,  1977).  SAINT  has 
been  used  by  the  Air  Force  Human  Resources  Labora¬ 
tory  to  explore  the  feasibility  of  employing  com¬ 
puter  simulation  for  evaluating  human  effects  on 
nuclear  systems  safety  in  a  missile  loading  oper¬ 
ation  (Askren,  et  al.,  1976).  SAINT  was  used  by 
Air  Force  Weapons  Laboratory  to  examine  workload 
sharing  and  nuclear  radiation  effects  on  pilot 
performance  in  an  air-to-air  refueling  mission 
(Wortman,  et  al.,  1975).  SAINT  has  been  used  by 
Purdue  University  researchers  to  investigate  the 
effect  of  higher  degrees  of  automation,  different 
capacities  of  process  limiting  operations,  and 
alternative  task  allocations  on  the  operator's 
idle  times  in  a  hot  strip  mill  (Maltas  and  Buck, 
1975).  SAINT  has  been  used  by  the  U.S.  Department 
of  Commerce  office  of  Telecommunications  to  analyze 
communication  frequency  utilization  in  a  railroad 
switching  yard.  SAINT  has  been  used  by  New  Mexico 
State  to  compare  theoretical  human  performance 
predictions  with  empirically  derived  performance 
data  (Teichner,  1976).  SAINT  is  being  employed  by 
Pritsker  and  Associates  in  support  of  the  Army 
Research  Institute  to  analyze  human  system  per¬ 
formance  in  an  AN/TSQ-73  guided  missile  air  defense 
system  operation.  Since  this  work  is  in  progress 
at  this  time,  it  has  yet  to  be  documented.  SAINT 
is  also  being  utilized  by  several  universities 
both  in  the  classroom  and  for  research  activities. 
Among  these  are  Purdue,  Iowa  State,  and  North 
Carolina  State. 
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